Skip to content

feat(remote): add auth --store for a persistent control-plane credential - #186

Merged
outofcoffee merged 3 commits into
mainfrom
persistent-aws-creds
Sep 8, 2026
Merged

outofcoffee merged 3 commits into
mainfrom
persistent-aws-creds

Conversation

@outofcoffee

Copy link
Copy Markdown
Collaborator

spinloop remote auth --store keeps a long-lived access key for the control plane's own IAM user in the machine's OS keystore, so day-to-day remote control and fleet operations keep working between SSO log-ins.

Summary

  • The control plane stack creates an IAM user (cloud-vm-llm-remote-cli) with a stack-owned managed policy scoped to day-to-day control: invoke the control URLs, read instance logs, discover the stack, price an instance, and manage the user's own access keys
  • New spinloop remote auth subcommand: report the stored credential, --store (creates and verifies a new key, or rotates with the stored key alone), --clear (removes the entry and deletes the key on the AWS side)
  • Credential resolution is per region: explicit environment credentials or AWS_PROFILE first, then the stored key, then the standard chain; fleet operations on remote environments sign through the same resolution
  • The key is held in the OS keystore (Keychain, Credential Manager, Secret Service), or in an owner-only file under the config directory where no keystore is reachable; SPINLOOP_REMOTE_KEYSTORE=file selects the file store
  • Store verification retries InvalidClientTokenId on an exponential backoff — a freshly issued key takes seconds to become resolvable
  • Specs: new remote-auth capability, endpoint-provisioning and remote-endpoint updated, change archived as 2026-09-08-persistent-aws-creds

Implementation details

  • The user's policy is a managed policy rather than an inline one: IAM caps a user's aggregate inline policies at 2,048 characters and the seven control functions' invoke-URL grants do not fit in it (the first deploy failed with ServiceLimitExceeded); the managed limit is 6,144
  • The self-service iam ARN in the policy is built from pseudo parameters, because the policy attaches to the user it names and a direct reference would be a dependency cycle
  • Control planes deployed before this change have no control-plane user; auth --store against one fails naming spinloop remote bootstrap, which is safe to re-run

Closes #172

The control plane stack now creates an IAM user with a stack-owned
managed policy scoped to day-to-day control, and spinloop remote auth
--store keeps an access key for it in the OS keystore (an owner-only
file where no keystore is reachable). Resolution is per region: explicit
environment credentials or a profile first, then the stored key, then
the standard chain. Control planes deployed before this change need a
re-bootstrap to gain the user.
@outofcoffee outofcoffee added the enhancement New feature or request label Sep 8, 2026
@outofcoffee
outofcoffee merged commit f9e3339 into main Sep 8, 2026
3 checks passed
@outofcoffee
outofcoffee deleted the persistent-aws-creds branch September 8, 2026 20:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

feat: long-lived control plane credentials

1 participant